request-server: add lstat support #379
Conversation
Add LstatFileLister, an optional interface for FileLister, if this interface is implemented Lstat requests will call it otherwirse they will be handled in the same way as Stat, as before
|
@puellanivis now that we have clarified the implementations details, what do you think about this pull request? For what I know this is one of the last missing pieces for the request-server, the other one is the support for the statvs packet. What are your plans for 2.0? I'm thinking to completly remove server/request-server and implementing a single SFTPFs interface with optional extension interfaces. Basically a model very similar to the one proposed here. I also would like to work on SFTP v6 support, using the new SFTPFs interface or extending the request-server. The server implementation is useless for my use case since it is only usable with local filesystem. Thank you |
|
I need to once over the code again, just to make sure I haven’t missed anything, now that I know the way it is working. For v2, I’ve been kind of thinking it might be good to separate the underlying network “wire format” away from the rest of the logic. So, providing a library that minimally exposes semantically-contained packets (you know, how we packed the structs just recently? We could change their order because the object had “semantic” scope, not “syntactic” scope.) Then ideally, if someone decides they would rather work with the raw packets or something, all power to them. Then, on top of that low-level → lowest meaningful-semantic-packets, we use the semantic “atoms” to build the design of a new unified API similar to the Ideas… but I haven’t really had much compelling force on such a massive refactor. |
Add LstatFileLister, an optional interface for FileLister, if this
interface is implemented Lstat requests will call it otherwirse they
will be handled in the same way as Stat, as before